OLTP (Online Transactional Processing) systems and OLAP (Online Analytical Processing) systems are used by the database community. OLTP systems are typically used in transaction oriented applications where a large number of short transaction (e.g., insert, update, delete, select) are made by the application. In OLTP systems, lists of elements are stored on a disk and are cached in a main memory of a database server. OLTP systems have generally been used with row-oriented relational databases.
OLAP systems are typically used in analytics oriented applications (e.g., analytical and financial planning applications) where queries are more complex. In OLAP systems, attributes are compressed using dictionaries and multi-dimensional queries can be made. OLAP systems have generally been used with column-oriented relational databases.
Due to the advantages of each system, OLTP and OLAP systems have traditionally been separate, and applications were designed to support one environment or the other. However, in recent years, the database community has witnessed a growing interest in in-memory computing and in parallel computing technologies. These technologies have resulted in OLTP and OLAP systems being utilized on the same database. For example, OLTP and OLAP transactions have been utilized on the same column-based in-memory database (e.g., SAP® HANA Database). Such efforts have been driven by an interest in reducing the total cost and complexity of the systems.
However, because each of the OLTP and OLAP systems is designed to efficiently operate on a specific type of database, running both of the OLTP and OLAP systems on the same type of database may have some disadvantages. For example, while utilizing OLAP systems on a column based storage database provides increased efficiency, utilizing OLTP systems on such a database does not increase efficiency as compared to performance of the OLTP system on a traditional row based database. Methodologies have been proposed to improve the performance of the OLTP system on column based in-memory database (e.g., pushing down the calculation logic to the database layer where it can be performed faster). However, even with these methodologies, the application code will still include queries to access required data from the database.